hckrnws

LLMs are always going to generate output (prose or code) in the same style as the training data. The Java training data corpus is both bloated/Enterprise-y, and mostly written by junior engineers or even students (because there are so many publicly-accessible Java school-project personal GitHub repos.)

If you're working on a Java project, consider prompting the AI to first write a "pseudocode solution" in a more concise/low boilerplate/"highly expressive" language — Ruby, for example — and then asking it to translate its own "pseudocode" into Java.

(Mind you, I'm not sure if you can modify the implicit system prompt used by automatic coding-assistance systems like Cursor. [Can you? Anyone know?] I'm more just thinking about how you'd do this if you were treating a ChatGPT-like chatbot as if it were StackOverflow — which is personally where I find most of the value in LLM-assisted coding.)

Alternately, consider prompting the AI to "act like a senior $lang engineer forced to write in Java for this project, who will attempt to retain their existing opinionated coding style they learned from decades of experience in $lang, in the Java code they write" — where $lang is either, once again, a more expressive language; or, more interestingly, a language with a community that skews away from junior engineers (i.e. a language that is rarely anyone's first programming language) and toward high-quality, well-engineered systems code rather than slop CRUD code. For example, Rust, or Erlang/Elixir.

(Funny enough, this is the exact same mental through-line that would lead a company to wanting to hire people with knowledge of these specific languages.)

> mostly written by junior engineers or even students (because there are so many publicly-accessible Java school-project personal GitHub repos.)

I used to work at a Java shop a few years ago. Hated my time there since a. I was coming from a more pragmatic way of writing software in C and Java and its ecosystem made me pull my hair out and b. came across several very senior engineers who insisted on writing code with factories and builders and obscure design patterns which made no sense to me. They were all straight from praying at the altar of Design Patterns and always found a way to give comments about a future scenario where this would be refactored.

I was fairly convinced that design patterns in OOP languages were conceived by relatively senior folks as a form of gate keeping.

(rant incoming)

I wish C was better. A company I have to interact with at $work managed to involve 10 different processes just to change wifi network name (it all boils down to a single netlink message to the driver). And eventually there were too many daemons so they replaced the entire thing with a new architecture where everything ran in one process but with many threads, with no regard for thread safety and blindly copy pasting hostapd code all over the place.

Everything is passed and parsed as a string, so you get none of the advantages of C (speed, simplicity) and all of the drawbacks (ABI breaking, etc.). To make matters worse, these people apparently haven't heard of databases or even plain text files. Data is stored in XML or JSON "databases", but of course having a full XML parser is too expensive so it's actually their own homemade XML parser which requires line breaks in certain places and literally does strchr('<').

The funniest thing was when they replaced dbus with their proprietary data bus (with zero debugging capabilities of course) because dbus was "too slow", meanwhile at the same time their "hashmap" is actually a linked list (!!!) because they thought it would be premature optimization to write a proper map type. All written in C and yet somehow slower than python.

I'm really looking forward to the stone age of programming, because we're definitely not there yet.

While rooted in actual use cases, I agree that often the GoF and other patterns are applied when there’s no need. My guiding principle nowadays is deletability/unpluggability - structuring things in a way that removing a component or behavior is as easy as possible. I do need the same patterns to achieve this, but I don’t blindly apply them, and use them way less as a result. Eg, with Swift‘s value types and great closure support, I can often go 90% of the way just with structs - no interfaces (protocols) or classes needed.

> came across several very senior engineers who insisted on writing code with factories and builders and obscure design patterns which made no sense to me.

In a large-enough Java codebase, with good software engineering being done, you will eventually hit the problems for which these weird kinds of indirection are the solution (because Java is dumb and forces them) — but it tends to take a while, and not involve concerns that are the first priority in a greenfield project. I'll just address the factory-pattern here, but the builder-pattern has a similar story.

The Java factory-uber-alles mode of thought (i.e. "make all your Java classes factories; and all your static methods, including constructors, into instance methods on those factories") exists because doing any kind of sum-typing on Class objects in Java is painful.

Java has interfaces. But Java has no concept of type-level interfaces.

In theory, Java could have:

1. extended the definition of interfaces, to validate that certain static methods and constructor signatures exist within the Class objects of implementing classes;

2. and then introduced something like a ClassWithInterface<T> type, that a Class object could be cast to if-and-only-if that class (or one of its ancestors) implements that interface.

But Java never did this.

And even if it did, by definition, a Java interface must still be known to the class defining it, and the membership of the class in the interface declared explicitly by the implementing class.

Which means it's a bit too late to make this change now, for it to ever have any kind of useful impact — there's so much existing Java code that can't be changed [old stable JDK versions everyone depends on; third-party libraries that are basically abandonware; etc], which would therefore not have defined membership in whichever later-defined type-level interfaces these types really should have type-level membership in.

And even if this were part of Java from the beginning, you'd still have the situation where you want to "make" a third-party class part of a type that the maintainer of that class doesn't think it should be a member of. (Maybe because that type-level interface is a private one you're defining within your app!)

With type-level interfaces, you could put a Class object into a type-level-interface-typed variable, and then use that variable to invoke the static methods of that class, construct instances of the class, etc.

But because you don't have type-level interfaces, to interact with a Class object "generically", you instead have to resort to using the java.lang.reflect package — which, depending on the method, either 1. accepts and returns plain Objects (resulting in extremely error-prone code); or 2. requires that you gradually find the right method handle (and catch five possible exceptions); pack the parameters for calling it (and catch five more possible exceptions); call it (and catch five possible exceptions besides the ones the typing yourself); do any return-type coercion yourself (three more exceptions)... and where all of those exceptions are extremely opaque and obscure the "actual" error (e.g. the caller passing an argument of the wrong type.)

Which means that any time you might want to take code that calls a static method on a Class, and instead make that code call a static method on the value of a Class-typed variable... you're now in for a world of hurt. Dependency injection? Mocks in unit tests? Strategy/adapter patterns? Plugins systems? All become the hairiest Java code in the world.

...until eventually you get fed up, and realize that you can have type-level interfaces today, by just taking the statics and constructors on these classes (that you may or may not own); creating equivalent wrapper instance methods on little proxy classes you do own; and then make all those little proxy classes implement an interface. Bing-boom-bam, you now have a "type-level-interface"-typed variable (i.e. a variable typed as the regular interface type implemented by these proxy classes), that you can (through these proxies) invoke these static methods and constructors on.

What do you call these little proxies only intended to wrap statics and constructors? Well, how about "factories", since statics+constructors tend to mostly be used to make instances?

I think you misunderstood the OP; they were comparing two different conditions (Java slop vs. LLM slop), because they think there's a common cause (tooling lets people make overly complex systems that still kinda work but are difficult to understand).

As far as I could tell the OP was not saying, at all, that the LLM slop was written in Java.

> LLMs are always going to generate output (prose or code) in the same style as the training data.

There's also an implicit bias towards blathering in LLM output, especially in open-ended scenarios like code completion. Language models prefer high-probability outputs; if it's appropriate for a model to generate highly stereotypical content like boilerplate getters/setters and documentation comments, it's more likely to generate that than something more application-specific like the actual implementation of an algorithm.

> It's also hard to tell them not to use AI because the code does work.

If they are still looking to have humans maintain the code, and hire people to optimize it, the at use case needs to be taken into account. From that perspective, I would argue that it doesn’t work.

You could/should charge a higher rate for companies that have a bigger mess to clean up. A cleaning crew is going to charge more to clean up a hoard than to do some light cleaning and re-organizing. The price reflects the effort involved, and I don’t see this as any different. They can choose to pay to write clean code up front, or pay for it later with difficult or impossible maintenance. The choice is theirs.

Personally, everyone on my team hates AI and it’s rarely used. I probably use it the most, which is maybe 4 or 5 times a month to write a single line here or there, mostly to save me a search for syntax.

I'm a undergrad studying CompE at a US University. I just got done with a group project, and I can confidently say that my opinion of AI generated code has changed a lot since I started. 3 of our 5 members had zero idea what their code did, they just had ChatGPT generate whatever they needed. The amount of bugs they introduced with each pull request was insane - this is definitely going to be a much bigger issue going forward as more IDE's start implementing LLM's in their UI.

I'm not going to act like I don't use ChatGPT, but I use it to understand things I don't know - like documenting code, helping fix bugs, etc. Never to just write code blindly, I'm just thankful I don't need to maintain the project once I'm done.

The only way I can see this being fixed moving forward is either a breakthrough in coding focused LLM's, or just banning AI generated code entierly (which I'm not even sure how to do).

Recently read a [similar article][1] and I couldn't agree more.

Essentially, you need to stringent the code review and testing processes. You cannot have AI doing code generation and code review and/or testing together. Either you have code generated by AI, and have Humans review and test the code, or have humans write the code and AI supporting with code review and/or testing the code. Never both.

I find the second approach better - AI supporting with testing and code review processes. Code generation is still Developer's domain and I don't see AI writing Production level code anytime soon. Developers can use AI to generate snippets of code which is then adjusted to make it production ready. That is probably best of both worlds at the moment.

  [1]: https://rdel.substack.com/p/rdel-57-what-are-the-most-common

Yes, but OP is being brought in after the fact.

Building software is like building a house.

If you are given a house with a bad foundation, and need to build on it, literally your only option for improvement is to see if anything can be salvaged, and then you start over.. ideally not making the same mistakes the next time.

It sounds like there's going to be a market for specialized AI-models to do code reviews and refactoring.

Perhaps we will see new specialized adversarial models develop focused on minimizing slop output from regular generative models.

We'll need more chips and power plants.

You don't need special models. The current ones can do decent code review as long as:

- you define exactly what you want out of the review - spell out that you want low abstraction, straightforward code, limit indirection (and a hundred other rules)

- provide enough code context for the review, which is tricky to do without effectively sending the whole project

But the models are already capable. Using them effectively is the tricky part.

Expertise and good verification automation tools: TLA+, Coq/Agda/Lean, specification synthesis, property-based testing, good old unit + functional testing, and elbow grease.

It won't be dissimilar to being a consultant now. I've spent years consulting where my job was to tame legacy code (that is, code which is not under test and nobody knows how it works). The value in roles like this is that you work at a level higher than the code in order to get the team able to understand the system and be able to start extending it again.

Thank you for spending the time to write this comment. As a solution architect, I don't write production-level code. I did not know of anything beyond unit / functional testing in verification automation.

> So how are you all handling this problem?

Increasing my per-hour rate until I'm comfortable spending hundreds of hours unspaghettifying code.

That is the right answer. I usually charge 2-5k euros to take a quick look and then, depending on what I find, I will charge 200-500 euros/hr to start working. Currently, human written code, mostly older php will demand the highest rate; asp/vba does a good job as well at being terribly written. Overarchitected things are usually in java/c# which I find annoying but not as hard; cobol, fortran and c/c++ are usually ok. Other things we don't really encounter besides a lot of scripts in bash and perl and tcl: usually fine ( mostly don't touch them as they work ).

The only thing to do is document the heck out of it with misleading comments, post it to github, and have other people link to the project, give it stars, interact with it. Continue reinforcing the machine's ego, pay it complements for its output. If we all do this enough, the GPTs will choke on the garbage and hasten the next AI winter. Do it for humanity.

This will get much, much worse. Better strap in.

To me software seems like an arms race because while it’s expensive to develop, the marginal cost to run it is very low. As long as companies continue to find way to increase their competitiveness through software, there will always be more work for software engineers as more and more of them are consumed by maintenance of existing software.

That’s why the 2000s outsourcing wave didn’t really impact the market for software engineers in the US despite the apocalyptic rhetoric at the time. If Company A has a productive local dev team, their competitor B has to either hire their own or hire a bigger outsourced team to stay competitive. Then company A has to hire even more to meet exec’s growth targets and it becomes a competitive spiral unless economic conditions change (like recently with elimination of ZIRP).

I think in the near future, LLMs will put that arms race on overdrive and all of us will have to adapt. They’re here to stay, for better or worse.

I handle it by using AI tools for understanding codebases and code reviews. Properly set up, LLMs can even give decent refactoring advice - i.e. by feeding it a callgraph - but the UX isn’t there yet. I use cli apps and custom scripts to do a lot of codebase work with LLMs like claude-sync and aider.

I’d start by trying out aider/Cursor to see whether they can help you manage the code. Use aider’s repomap or Cursor’s repo indexing features and ask the LLM questions about the codebase. Use the Cursor code review feature, which has caught a lot of subtle bugs for me (I ignored the feature for my first month and was pleasantly surprised when I first used it in lieu of debugging a PR). Experiment with asking the LLM to refactor the codebase since now their token windows are large enough to fit ten thousand plus lines. Maybe try Github Copilot Chat if you can get beta access, since they do codebase indexing too.

My advice boils down to “fight fire with fire”. In the hands of competent engineers, LLMs are a lot more powerful than the slop you’re seeing. (For context I’m working at the intersection of C++/Rust/Qt for which training data is basically nonexistent)

> marginal cost to run it is very low

I think this isn't particularly true, in general. I'll give an example of how this assumption can bite an early stage startup rather badly.

Company X rapidly develops some idea, raises seed round, hires some devs. At this point they have no customers or traffic so infrastructure costs are low and software development costs dominate. Moreover, they have $100k of free Amazon bucks to play with so they're not really thinking about infrastructure costs. Then they get a customer or two, and all of a sudden infrastructure costs are huge and the small dev team has to reorient in a panic towards figuring out how to make their thing efficient--basically an unplanned total rewrite. The opportunity cost of that could actually sink the company or force them to raise a round on bad terms.

In the public cloud, there are many ways you can very quickly rack up a huge bill if you don't do things efficiently. Some examples:

1. Let's just use AWS Lambda for everything!

2. Let's use AWS managed kuberneetus!

3. Let's write a bunch of small files to S3!

4. Let's not think too hard about what our data looks like on the wire, and just ignore data transfer fees!

These costs may look small at first, but they probably scale more rapidly than your revenue does. There's absolutely no substitute for just doing it consistently right, from the very beginning, and not deviating.

The marginal cost of each of those is very low, especially stuff like S3 and Lambda. You used to have to rent enough dedicated servers or VMs to handle your traffic and before that buy racks of storage and servers to run software. Now it's literally paid by the minute/gigabyte as you use it instead of having to invest in it upfront.

Just because companies are bad at cost management and bloat their stacks in clouds doesn't mean that the marginal cost is high, just that their absolute budget is. The marginal cost of compute and the marginal cost of each new customer using it are different issues.

Yes, but the marginal cost isn't actually that low that you can use these things willy-nilly without actually calculating and thinking about it. So the idea that "dev time is expensive, computers are cheap" just isn't true.

So a system which automatically generates a bunch of inefficient, poorly wrought crap quickly for low effort will make you pay for it in different ways. So it's not obviously advantageous, and it seems (to me at least) the disadvantages are greater.

I never said that you don't have to think about it nor did I say that "dev time is expensive, computers are cheap." What I said was that the "while [software is] expensive to develop, marginal cost to run it is very low." Those are completely different statements, although I could have been more specific.

Low marginal cost is built into the cloud products like Lambda, S3, and autoscaling VMs. That's why they're popular, even though the servers running those services are much more expensive.

Edit: I think I see the impedance mismatch here. Yes the marginal cost of spinning up another RDB instance or big VM is relatively high, but unless you’re spinning up one for each customer, the marginal cost per user is much lower. Sometimes the marginal cost is recalculated like when scaling up to more big DB instances, but the cost per unit is very low compared to say a factory that has to buy machines up front and train machinists when they need to grow. If a software company has enough servers already, the marginal cost of a new customer is often just the extra electricity used by existing compute

What I was trying to get at is that although the absolute cost of e.g. S3 API calls seems low (you get 1M of them for $5), the marginal cost (cost increase from adding one customer) can actually be very large if you make a lot of API calls. So much so that it actually causes serious problems. Cloud pricing can be very sensitive to usage, so in data intensive industries--say security monitoring, where customers may send you 1TB of logs per day--the seemingly low cost of cloud conveniences actually can be very misleading if you're not using them properly.

I agree that for example, serving a web page to users where almost everything happens on the client, the marginal cost of running the software is low. But it's not always true, and it's really important to measure and track these costs otherwise you can end up in a bad way. I've seen it happen ;).

That's actually how the demand for software engineers will only grow with AI. CEOs will develop terrible but successful MVPs and will soon need to hire a competent professional to go the next mile

I find the issue is there is too much or too little abstraction in people's prompts to do technical tasks.

There is proven value in first having CoT conversation to verify the scope, design and architecture, and only then begin to implement it.

At the same time, folk sare using Cursor with markdown files to maintain this information at all times (per prompt to be included), which significantly appears to increase the code quality and writing code how you want. Having a coding style instruction list is critical.

Java is an interesting beast though, it's got so much built in just a call away. No environments to mess with, no packages to really install, you get the whole universe available. For this, there are some better coding specific models, one of which is DeepSeek.

This model is almost exclusively coding right now, and the last I checked, their 2.5 model is outperforming Sonnet, and it's self-hostable.

I'd probably combine this with something like aider.chat to begin with.

There has been a bit more luck using something like aider.chat for coding things off the python/javascript/php trail.

The main thing I'm learning from coding youtube right now is there's a lot of ways that people code. Some think it through before, as they go, not at all and the results can vary, and there's no perfect way to do it.

Knowing what to ask, where, in which way is the secret that I've found. Often starting with Claude/GPT 4o on the web is better to get the inputs ready to put into a coding environment to begin.

I don't have this problem, but Cursor was an excellent companion yesterday while I was scripting in Python. It was always ready with function suggestions—sometimes just typing the function name and hitting tab twice. Other times, I used cmd+k for descriptions. What worries me is that writing functions is easy, but keeping everything in my head to write more functions later, especially after 20 days, is challenging.

(When I tried with Zig it was a disaster..)

Software is hard. AI can radically simplify this by writing the code for you, but that comes at a cost. If you don’t understand what was written, or you only understand it at a superficial level, maintenance is going to be a nightmare. It isn’t uncommon to come back to code you wrote yourself, say, 20 days ago, and need to reacquaint yourself. Extend that to AI.

I’d argue that relying on a tool like cursor to bang out whole routines and types, just using it as “advanced intellisense”, takes away from you truly understanding the solution you’re putting together. It’s fantastic if they make you more productive in the short term, but in the long term, if the generated code is convoluted, difficult to revisit, that’s where you (or a future maintainer like OP) are going to kill time.

When working with other engineers using IDEs like VSCode, while I was using vim, I ran into a similar dynamic. I relied on grep to find and trace code, whereas they were right-click go to definition. That ease of navigation made them insensitive to the amount of indirection in the code base that didn't need to be there.

It was an uphill battle, and honestly, for that time, I just switched to the editors they were using. Otherwise, I'd just be seen as being less productive.

For my own personal projects, I could spend more time just keeping things simple, and using vim. Though recently, I've switched to VScode based Cursor. I've found that it works best when I use it as a guide, rather than as a code writer. I'm often working on an atypical stack, and the code it generates just uses a wrong or outdated API. Even cursor is terrible at pulling in the right context and documentation. The mental habit of thinking it'll "just solve the problem" is wrong too, and wastes my time. It's much better if I think of it as a guide, and I ask it to explain everything I need to do step by step, so I'm following along, rather than expecting it to one-shot it all for me.

So, in some sense, you'll probably need to go with the flow. Using some sourcegraph or other tooling to help you navigate will help in the short term.

But I think in this sense, I agree with the handmade people--that keeping things short, simple, and fast will be a business advantage over time. But that's given that you've validated the need. And find companies that understand that AI won't be able to one-shot tasks (beyond very typical junior programming tasks) for a while to come.

AI should assist, not replace, skilled coding. It's crucial to blend AI efficiency with human craftsmanship for clean, sustainable code. From my consulting experience, excessive AI reliance results in bloated code that’s a nightmare to maintain. This echoes the problem Java shops faced with class and object overuse, but now it’s amplified.

You deal with it using AI. The difference is that you can provide better guidance than someone with inadequate development experience. Better guidance leads to a better (ie cleaner) result.

You might as well get good at this now, because the future is AI generated code and AI assisted code maintenance. And by the future, I mean the present.

And if by the present you mean garbage, then sure.

Maintaining bad AI code is the new maintaining bad offshore code.

oh man I have some nightmares from having to do that. The biggest difference is that it doesn't take a week for revisions (or having to have a late/early call)

> It's also hard to tell them not to use AI because the code does work.

It sometimes "works on their machine". As you aptly pointed out - it often has serious design issues.

> So how are you all handling this problem?

Do nothing. The problem will resolve itself. Eventually tech debt will crush them. Probably soon.

Have you tried using Agents that have system prompts that tell AI not just what you want to produce (java, python, typescript,...) but also include best practices to follow?

You can even give examples of what to do (simplify and stick to the objective) and what not to do (verbose and non-value add).

Although code never works the first time, has happened that AI suggested some nice abstraction and changed some function and variables naming to make it easier for me to remember next time...

I also prefer spoon-feeding AI and having a conversation about specific pieces of code to refactor, or features to add. That leads to smaller and more pragmatic use of AI vs the "build me an app that does XYZ in 2 seconds" that leads to code-dump mode.

I’m having a lot of trouble following this. It seems to be related to Java while simultaneously having nothing to do with Java.

What actual problem are you running into?

If it’s purely that gen AI produces slop, that’s par for the course in consulting with startups. You will find a lot of humans willing to generate slop all on their own. Some will even do it for free. Fundamentally, if your client could figure it out themselves they wouldn’t be paying your hourly so slop represents part of the opportunity space.

LLMs will just create new opportunities in consulting. But the game is fundamentally the same - communicate about what you understand versus what you don’t, ask a lot of questions and underpromise in the beginning.

We were all ranked together at the valuation. Men and women, old and young, married and single, were ranked with horses, sheep, and swine. 1. What is the meaning of the word "valuation" in this passage?

Responses

A Buying an item Buying an item

B Figuring out how much something is worth Figuring out how much something is worth

C Fixing a broken object Fixing a broken object

D Getting a good deal on a purchase

Getting a good deal on a purchase

We were all ranked together at the valuation. Men and women, old and young, married and single, were ranked with horses, sheep, and swine. 1. What is the meaning of the word "valuation" in this passage?

Responses

A Buying an item Buying an item

B Figuring out how much something is worth Figuring out how much something is worth

C Fixing a broken object Fixing a broken object

D Getting a good deal on a purchase

Getting a good deal on a purchase

We were all ranked together at the valuation. Men and women, old and young, married and single, were ranked with horses, sheep, and swine. 1. What is the meaning of the word "valuation" in this passage?

Responses

A Buying an item Buying an item

B Figuring out how much something is worth Figuring out how much something is worth

C Fixing a broken object Fixing a broken object

D Getting a good deal on a purchase

Getting a good deal on a purchase

I just hope it leads to non-technical people not meddling in or starting tech startups where they have no f'ing idea what they're talking about or doing.

Stick to the scams and whatever else, or go work at a PE firm.

Source: my experience working with such types.

It's one of the biggest "problems" with LLM coding styles. It creates large blocks of code very fast, but the quality might be dubious and takes time to dig through. Same story with unit tests, e2e tests etc.

If it saves you time to fix it, it's still a win. If you find yourself spending more time debugging, just write it by hand. There's a lot of investors that want to "make AI happen" but the truth is more nuanced. If it works, use it. LLMs aren't good or bad, they are just another tool.

This tale is older than genai. I've had this exact problem multiple times in my career, and it's usually very lucrative, especially if you're billing by the hour.

i did this in a django shop where they had comparable class/code bloat/brokenness everywhere. rolled their own security. multiple race conditions. broken and anti-user frontend.

1. put together a big process flow diagram showing some of the dead code paths and ridiculous complexity and how it is causing bugs — show what they’ve done. show them the problem.

2. show a diagram of a comparable/desirable stack (ie fewer bugs/easier to change) — what you would have done. show them the solution.

3. put forward a longer term contract or something. basically charge more to rewrite the whole thing — what it’s going to cost them and how they need to commit to change.

-

step three is important. i would not move forward today if they don’t make a suitable commitment. hand wavy verbal statements are not good enough. getting something written on paper is key.

if they’re not willing to write it down then walk away — they haven’t had enough pain yet and aren’t willing to change their approach.

i did not get written down commitment from the django shop and i regret it. i am no longer there (and much happier).

I use chatgpt a lot for typescript. The code is good/okay but I usually ask for a round of refactoring and then do some more cleanup myself.

It definitely saves some time and reduces cognitive load for me.

But at the moment I'd not trust the output blindly.

I have not used LLMs to generate larger codebases.

I don't think the tech is there yet where you can get a bot to make a good contribution to a codebase on its own.

> It's also hard to tell them not to use AI because the code does work. I would say even most of the times the code does work.

> But it's just written in the worst possible manner and maintaining it long term is going to be so much harder if instead they had just handwritten the code.

Just charge more for LLM generated crappy code due to above reasons?

Fixing up spaghetti code sounds like an excellent job for source-to-source transformation systems.

Are you talking about single founders? It's completely OK for a non-tech person to start his idea with shitty code they wrote themselves and pay real professionals to untangle it later. AI didn't change that.

Sloppy code usually has sloppy ideas behind it. Clear thinking begets competent execution. I'd be really wary of any codebase that doesn't pass the smell test, because usually when you really get into it you find flawed premises left and right.

To play the devil's advocate: AI allows non-tech people to bootstrap a functional application. A global good design may be missing when the code is generated in small quantities and stitched together. It's sloppy in the sense that it cannot be maintained and extended easily but it works™

The ideas underlying the implementation are not necessarily tied to the implementation given the skill gap.

Ok, but how long does it work™ for? I don't know of any "immutable businesses" that are actually successful. Every single business out there from the corner store down the street to the largest megacorps are always changing things, experimenting, and trying to find a competitive edge. So it seems all the AI really did was allow this nontechnical founder to dig themselves and any customers unfortunate enough to trust them very deeply into a hole.

This is true for professional developers. I'm talking about people who are not developers, and may not understand even the most basic programming concepts, like variables, loops or functions.

I don't think such people would be able to compile, let alone scale and operate the software, maintain databases, reverse proxies, manage logs, configure monitoring, etc. It's hard to think of any real world use for a tool which spits out a "website for X" unless it's going to own it in production as well. But it can't. So all it does is rack up a huge amount of technical debt right at the start.

Don’t use an LLM to write code. That’s how I deal with it.

Hold strong, keep noticing and articulating problems as they arise, build bridges to people willing to do it the hard way, and reward good behaviour.

Is cursor the new co-pilot now?

It's totally different in practice. Copilot is sparkling autocomplete in comparison. Cursor suggests changes outside of your current position and has the context of what's happened before. It also lets you prompt for changes you want implemented, but that's something it have to explicitly do. Without prompting for actions, Cursor's suggestions when editing are scary good most of the time.

Get wha you pay for. Cheap ai isn’t good Good work ain’t cheap.

> My theory is that Java is actually a pretty reasonable good language

Bold.

sounds like terrible work and you should say "No thanks"

[flagged]

This is AI generated.

Funny that this gets downvoted when the original post is also AI generated

You dont have to deal with it. Only a question of time before better AI comes out and starts refactoring this to better looking code. These are just growing up pangs and one of those problems which should go away on their own.

The bigger problem is what to do of the humans who are fixing this sloppy code right now.